Speccy ClassiX 1998/Speccy ClassiX 98.iso/amiga_system/the_aminet/comm/bbs/maxsbbsus.lha/MAX154/Readme.tbm

Text File | 1995-09-29 | 42KB | 794 lines

Notes from the BenchMaster:


  Well, me and JJ checked 'em all, and this is the one.  Others came close,
but they'd be missing some integral piece, like no multiple nodes or full-
screen message base editor.  As I got the program up and running and made my
way through the manual, I discovered more and more neat stuff as I went
along.  Here's a basic rundown of the features, in case you missed some:

> As far as I can tell, this is the fastest BBS software on the planet.
  Average 14.4 download rates are 1500-1700+.  This is with a Hayes 28.8
  modem on my end, set at 38400 in the BBS configs.

> Uses "binary ANSI" menus for that modern, snappy feel.

> You can attach LHA files to public OR private messages.

> Best full-screen message base editor I've ever seen, by far.

> Really cool way to mark files for auto-downloading.

> The Internode Chat is an absolute panic with multiple lines plus local.

> Supports infinite nodes, infinite path names to file areas, upload resume,
  fidonet, has an online user editor, and every color and scrap of text in
  the entire program is laid out in 300+ configurable little boxes in the
  Text Editor, a SysOp's dream.

                                     *

  Update Note:  I am now using the very excellent LZX program to compress my
board files.  For the sake of easy reading, though, I won't change any refer-
ences to LHA in this file.  If you're a SysOp, you owe it to yourself to
check this baby out.  The first of the "smart" archivers.

  Update Note II:  You can add "infinite file sections" to the above list,
with the use of the very-excellent DFB door, enclosed.

                                     *

  This has now been officially released to the PD, so I'm taking the liberty
of setting a few things up differently, more or less customizing it for the
USA from its odd Aussie look, no offense, Tony.  It's too bad he's dropped
support of it, but the good news is, as you'll see, this thing went through a
number of revisions, so it's fairly well polished.  It has flaws, and lacks a
few necessities, but when you weigh its deficiencies against all the plus
points, there's no contest.

  I was a BBS-PC SysOp for three years, and quite obviously Anthony was a big
fan of Pagliarulo's little gem, so I lapped this stuff right up.  Once you
get the hang of splitting up the menus into two pieces; the ANSI stuff that
you see, and all the parameters that go in the Configuration box, it's a
snap.  I estimate that I'm making menus from scratch in 10% of the time it
took me with BBS-PC and a text editor.  No matter how smart the text editor
was, how many macro keys I had going, how fast I was with ol' Snap, this
routine just blows it away.  LaDraw is very well done and very smart.

  The auto-download feature is a smash on my board, mainly the way you run
the up and down arrows through the files, marking files as you go.  Also, as
far as the full-screen message base editor goes, I've seen others, but this
is the first FULL "full screen editor" I've seen...most are more like two-
thirds screen, if that.  One quick note:  At some point we're going to have
to start calling full-screen editors "editors", and those older types "line
editors", to differentiate between the two, if ya follow me.


Start-up:

  In your startup-sequence, Assign BBS: to the directory the files are in.
No need if your device is named "BBS".

  When setting up your modem, most strings use &C1 and &D2, and any built-in
error-checking (MNP5) or compression method (ARQ) should be turned off.
ZModem takes care of any error-correction, and you can't compress LHA files
down enough to make any difference.  If you download large, 1-meg textfiles,
leave the built-in compression on.

  It also seems like there's always one odd init string command that has to
be tweaked.  With my Hayes, I had to switch the W0 command from "Do not
return negotiation progress messages" (default) to W2, "Do not return
negotiation progress messages and return CONNECT messages using modem-to-
modem (DCE) speeds instead of modem-to-DTE speeds", whatever THAT means.
Only took me about four hours and a hundred test calls to get to that one.
Fun, huh?  For my Supra, I'm presently using:

AT&F&C1&D2L0M0N1W2\N3&K3&Q5S0=1^M

  The "pro" way to save your settings is to write it to the modem's memory
with a "&W", then call it up from Max's with a "ATZ0^M", but I have a new
SupraExpress 14.4 modem that actually needs the init string to be in Max's,
so you'll have to experiment.  Mine won't set the Auto-Answer if called up
from internal memory, odd.

  With Max's, itself, as far as I know, the only thing you'll want to play
with is the "Locked bps rate" in the Modem Configure menu.  Two of my modems
(Hayes and Intel) like it on, the Okidata likes it off.  Have it in the wrong
position and oops, no connection.

  Fire up the program, if you haven't, and check out the pull-down menus.

  The Editors are the User Editor and the Files Editor, and when you save one
of the Editors, the results are immediate on all nodes.  The Config Menus are
the "MAX.config" file, but these settings are NOT available to the other
nodes until certain steps are taken.  If you're planning on going multi-line,
hold on to your hat, this is a real ride.

  When you get a handle on what's goin' on, hit Right-Amiga-L and log onto
the board.  Hit F6 to macro in the name and password, then check things out.
You have free license to throw away or alter any of these menus to your own
exact specifications.  I left some of my own menus in, others I purposefully
left bare to force you to have fun and be artistic. ;)

  You also need to set aside some time to read the manual.  Remember, it's
for the original version, so don't panic when you see that you're allowed a
whopping THREE sections for all your files or something.  You'll certainly
want to sit down and read the whole manual and updates once (at least) all
the way through, as some of the revisions were major.  That is, if you call
multiple nodes, infinite file paths and auto-downloading "major".

  I tacked the update manual to the bottom of the regular manual, so a Search
will pick up everything.  Also, he had his numerous revisions reversed, that
is, the latest one first, but that just made reading or searching through
them confusing, so I switched them around.  If you search for a key word now,
just keep searching and the last instructions you see will be the last
update.

  I'm not going to give any "instructions" here, that's the manual's job, I'm
just going to list out the problems I've run into, and my solutions.  When I
mention FakeKey and MovePointer, a general tittering among the crowd will be
tolerated, but after that, it's all business.  You want your skinny little
butt saved or not?  Welcome to your two new best buddies.

  I'll also include endless droves of misc thoughts and last-minutes notes,
because that's my job. ;)

                                     *

THE MULTIPLE NODES CONFIGURATION QUAGMIRE:

  Hey, multiple phone lines...cool!  And this wasn't part of the original
program, this is a "revision"!  Wow, SOME revision!!  Cool, cool, cool!

  Unfortunately, he forgot one little thing:

  The multiple nodes configuration box, where you enter in the different
modem parameters for the different nodes, then save them.

  Forgot, forgot, forgot!

  And I'll tell ya, I don't have a clue what he thought people were going to
do.  Or what HE was going to do, assuming he even actually had a multi-line
BBS.  Listen to this mess and pay attention:

  Let's say you have three phone lines.  That's a pretty realistic figure; if
you're going dual-line, the small extra hook-up fee for the third line and
the $10/month cost makes it well worth it.  Put an old scrap 2400 modem on it
and give it to the low-speed callers.  If nothing else, just for the prestige
of being able to say "multiple line" instead of "dual line". :)

  When you run node 1, you run it from an IconX or XIcon scriptfile, like so:

                           MAXsBBS MAX.config1

  Ditto nodes 2 and 3, with their own configs.  You pop open the Menu Editor
on node 1 and make a bunch of menu changes.  You save the config as
"MAX.config1".  Okay, fine, config1 has all the new menu changes in it.  You
make copies of it named "MAX.config2" and "MAX.config3", so the other two
nodes have all the new changes as well.

  But config1 also has node #1's modem settings, like modem speed, low baud
rate accepted, device name and serial unit number.  Uh-oh!  Your other two
modems aren't going to like that very much, so after you fire up nodes 2 and
3, you're going to have to go in to the Modem Editor and make those four
changes.  Every time you make the tiniest change to one menu.  And if some-
body's online at the time, you have to wait until they're off.  And wait.
And wait!  What a hassle.

  The other option, of course, is to open nodes 2 and 3 and make all the same
menu changes that you did to #1.  All of them.  Without mistake, every time
you make the smallest change.  And again, if one of the other nodes is busy at
the time, you have to wait.  And wait.  And maybe forget to make the change
later.  This nightmare makes the modem config business look easy!

  So the answer is to figure out exactly what binary characters in the
config file are being changed when you make just those modem config changes,
then have a patch program go in and make just those changes to the two new
config files.  I've enclosed FCMP, the program to tell the binary differen-
ces, and Fix1.1, the patch program I'm using, as well as my scriptfiles.

  Thankfully, the location where those characters are written is always the
same, so the patch, itself, really isn't any big deal.  It looks for a
specific location, and changes whatever is there.  You'll first save config1,
then copy it over to config2 and config3, then run two patch programs, one on
#2 and one on #3.  That way all the new menu changes, etc, are identical, but
the modem configurations are different.

  Whew!

                                     *

RESOLUTION MADNESS:

  Oops.  One little itty-bitty problem.

  It's written for an Aussie's PAL machine, and you got an NTSC machine.  Go
ahead, use your favorite PAL screen changer or your Prefs tools.  Pop up the
BBS, log on, and see if all four lines of the stats box down below and the
title bar up above are visible.  And, of course, everything on the Workbench,
DU, etc, are lined up right.  Are you also seeing the bottom row of gadget
boxes in the Editors and Config menus?  If "yes", skip to next section.

  If "no", try using one of the later versions of Degrader or tweaking around
with your Preferences some more.  If still no, try using little, tiny,
ancient Degrader 1.00, enclosed.  Also, make sure the Pref's Screen Modes are
in PAL-Hires and fiddle with the Overscan.  AND fiddle with the vertical
adjustments on the monitor.  AND possibly filezap the system-config file in
devs.  AND-

  Between all of that, you'll see the BBS's title bar, all four lines of the
stats box, and all the editor gadgets.  Probably.

  If you don't, it's not that big a loss.  Actually, I'm not using it now,
because I didn't like how much slower the machine was without SetCPU (which
won't work with Degrader) and I found the whole system in PAL a bit flaky,
locking up occasionally, whatever.  But if you want it, go for it.

  Without it, you'll probably just see two lines on the status box, and
you'll have to pull the Editors up to the top of the screen to access the
lower buttons, no big deal.

                                     *

THE NODES-IN-THE-RIGHT-ORDER CONUNDRUM:

  I immediately found out that there was one little hitch to running the
nodes from a scriptfile, like the st-seq, as referred to running them one-
by-one from the Workbench.  It has to do with the order in which the screens
are presented.

  Let's say you want node #1 to be the "main" node, and it gets the fastest
modem.  Nodes 2 and 3 are the lesser nodes and have slower modems.  Node #4
is yours (sleep mode), and you want all four fired up.

  You fire up node 1 from the WB, it pops up, then you click in the gadget
box to get back to the WB, then click on the icon for node 2.  You click back
to the WB and repeat for 3 and 4.  When you go through the screens, every-
thing is perfect:  You see nodes 1,2,3 and 4 in order, #1 is your fast line,
#4 is yours.

  If you run 1-2-3-4 from the startup-sequence, #1 will be your hot line, all
right, but when you go through them screen-by-screen, they'll be reversed,
4-3-2-1.  If you reverse the order in the st-seq, they'll be displayed
1-2-3-4, but now #1 will by your node and #4 will be the hot line.

  MovePointer and FakeKey save the day!

  These two guys can simulate anything you can do on the computer with the
mouse or keyboard, so they can do the fire-up-from-the-WB routine for you.
You can actually have them double-click on the icons, but that's unneces-
sary.  (although it looks terrific)

  You write up a scriptfile to Execute, either through an icon or as part of
the startup-sequence.  It first fires up node 1 and waits a few seconds for
the modem to initialize.  It then has MovePointer move up to the screen's
gadget box, then FakeKey simulates a left mouse click, getting you around to
the Workbench.  MovePointer moves the pointer down and to the left a bit,
then FK clicks on the Workbench to activate it.  The scriptfile continues,
firing up node 2, again waits a few seconds for the second modem, then MP and
FK get you back to the Workbench, where the steps are repeated for any
remaining nodes.

  Now, the nodes are correct, and the screens are in the right order.

  What do you mean, "kludge"??

                                     *

THE BIG BATCH LOGON TRICK:

(Note: this section is made obsolete by the DFB program, but I'll leave it in
just for reference)

  One thing missing from this little rascal is a way to log on a whole bunch
of files to just one section.  The trick is to have a separate config file
just for batch logons.

  Load up the BBS, go to the Sections Menu, and remove every "Fil:" check-
mark from every section.  Close the window and save the config as "config-
.batch" or something.  The deal here is when you ADD a new file, the section
box on the Files Editor goes to the first available (checkmarked) section.

  If you're going to log on a bunch of files to section 20, first load up the
config.batch file, then go to the Section Menu and activate just section 20's
"Fil:" box.  Now pop up the Files Editor.  Voila!  Section 20 is now the
first available file section, so that's where everything goes as you log them
on.  When you get through adding all the files remember to reload your normal
config file.  Piece o' cake.

                                     *

THE JUNK MAIL BONANZA BOO-BOO:

  There are a couple of things slightly wrong with the way it's set up to log
on new users.  It gives them a few choices they shouldn't have, like "Want
screen clearing codes?" and "Pause at end of page?", and most especially, the
Junk Mail flag.  If you're a new user, you might figure that you DON'T want
your screens to be clear, you want to actually be able to read them, so you
might pick "no" for "screen clearing codes".  Some of the choices, like ANSI
colors and the full-screen editor should certainly be left in.

  The Junk Mail flag is a real loser.  If the Junk Mail flag is on, any mail
addressed to "All" will be marked.  Then when they read their marked mail,
either then or later, they have to wade through all the mail to "All" just to
see their own messages.  And they're going to see all the All messages when
they read "Read All Mail" a few minutes later, anyway, so what's the big
deal?  Besides, not everybody addresses their mail to everybody as "All",
lots of people do things like address them to "Niner Fans!" or whatever.  It
just doesn't work.

  I recommend they set their page length to 23, that seems to be the NTSC
equivalent to the original Aussie PAL 28.  In Options, if they hit Page
Length, I send them to a test menu, where they can both list the files and
read a long numbered-by-line textfile to test with.  This part of the system
is a little screwy, but what the hell.

                                     *

Misc Notes:

* Very important to remember:  Access levels DO NOT WORK from the local
keyboard.  Even if you call in from remote, you have to use the actual remote
keyboard for the access levels to work right.  Also, in the Menu configs, you
have to start with the highest level and work down.  When accessed from
local, you get whatever is the first one listed in the menu.

* Also very important to remember:  Do NOT file-zap the "MAX's" credit line
that you first see when you log on, right before the screen clearing code of
the login.text whisks it away.  The sneaky guy runs a checksum on it, and if
it's been changed, the program freezes up every night at midnight!

* Immediate habit to get into:  Putting the file's description in the LHA's
Filenote, what we used to call the "Comment Box" under 1.3.  Set it up so
your DU can do it, then enter in the description right after you LHA the
sucker, or copy the original over to your Ready dir.  It makes adding the
files later a snap.  You add the file, the Filenote automatically inserts
itself into the description box, you hit the Return to bring the cursor up to
the sections box, enter in the section number, that's it.  If you're doing
the batch-loading routine, you don't even need to hit the Return, nothing but
point and click.

  The other advantage is that possibly other smart BBS programs in the future
will also be able to use the Filenotes as descriptions, so, well, uh, you
see the point.

Update Note:  Well, it looks like little Filenote isn't going to be the
"universal file description" that I thought it might, seems this file_id.diz
file is the coming thing.  Filenotes DO have two major flaws (don't transfer
w/Zmodem and the Copy command wipes them out unless you remember to use the
"COM" string), so maybe it's just as well.  DFB looks for DIZ files first,
then Filenotes.

* If you allow more than about 2,000 messages in the system (Sections
Menu/Max #), your message data files are going to get pretty hefty, more
than a meg, and worse, the Continuous Read and Search features really start
getting bogged down.  I'm currently running the message data files out of
Stat Ram (SD0) and it's working pretty well, MUCH quicker than off the disk,
and I limit them to 3,000.  That's a few months' worth, that should be fine.
Hey, this is a message base, not a time capsule.

  Also, the Search feature in the Files area works MUCH faster with the files
data files in SD0, or any virtual device.  The new VD0 is supposed to be
much-improved.  If you only have enough room for either the files or message
data files, use the files.

* It makes it easier to just have a device named "BBS:", but then you can't
"assign BBS:" over to anything else, to run another version of Max's (like
this original) to check something out, so you'll have to decide if it's
worth it or not.  Might be easier just to stash the BBS files in some dir and
assign BBS: to it, so you can reassign it later.  I have it assigned on my
own computer, but the actual device name on the BBS computer.

* In case you missed it, as far as the File Attach feature goes, if it's
attached to a message to "All", anyone can get it.  Otherwise, only the
addressee can G)rab it, PD or private.  Also, if it's addressed to a single
individual, once they grab the file, it's deleted, but not to "All".  If
you're trying to intercept something before it's deleted, you could always
whip up a scriptfile that would run every five minutes or so and Protect
each file in the AttachedFiles directory from deletion, or if the directory's
usually empty, just copy everything in it over to another dir every once in a
while, whatever.

* I left all the original .text files in the Text directory, but put all my
own textfiles in a Txt directory, with six or seven subdirectories.

* Make sure your upload directory is in the "filepaths.text" text, or it
won't be able to find the files for deleting, when you delete them in the
Files Editor.  DON'T FORGET:  When you delete a file in the Files Editor and
hit the Save box, the program goes looking on the drives to delete the actual
file.  If you just want to temporarily delete a file, so you can log it back
on with the same name or something, make sure to first rename it first or
back it up!

* Your uploads will go to whatever directory is in the Filename/Name/Dest/-
Path box, very convenient.  What's wrong with the New Files Public on the
Paths & Options Menu is that they won't show up as N)ew in the Files Editor.
If you're not validating the files before putting them online, then you'll
want it on.

* If you're using the parnet system with a multiple-node BBS, you'll want to
check this out:  Let's say you only have one modem on your own computer, and
it uses the serial.device.  Let's say you have three lines on the BBS, using
three different serial devices, and you use node #4 as your editing node.
That node should use the same .config file as whatever node is using that
machine's Commodore serial.device.  So when you save the .config file, then
copy it over to your own computer, that "serial.device" will be acceptable to
your own Max's program and it'll run.  If you have some other serial device
name in there, the program won't run since you don't have the device
available on your computer.  Just putting the device driver in your devs
directory won't work, it has to be hooked up.

* An interesting feature that I found out about while watching the members
screw up their Download name entries was that the manual download requester
takes keywords!  If you want to download "SysInfo52.lha", type in "sysi" and
pow, there it is.  If you just typed "sys", it might go through a couple of
selections before finding it.

* The local macro keys work fine with "^M" as the CR, but calling from
remote, the members will probably have to use a "\n" or "\r", or whatever is
their term program's CR key.  Pointing out to your members how to set up that
one-step login macro is cool.  Make sure to test it from remote first.

* Don't forget the Raw Download function, #37, for files that you don't want
to bother logging onto the board.  I have a "CD Of The Month" feature, but all
files must be downloaded raw with full paths to CD0.  No sweat, I lay out all
the pathnames for them on a special download menu, and suggest they use Snap
or macro keys for the ones they use a lot, like "CD0:Gifs/Nudies/". ;>

* Also don't forget to use "straight downloads", function #24, with the full
path to the file in the Filename/Name/Dest/Path box.  This is basically the
only way you can get around the 100 sections limitation thing.  For example,
I used to have about ten virus programs in a section.  There's only a couple
that are really needed (and kept current), so, in my burning desire for
another section, I ended up just whipping up a straight download menu and
sticking the virus programs on that.  For the very few that are kept updated,
I also load those onto the regular board, sticking them in Misc Utils, just
so everybody can see them as they list New Files.

* The Internode Chat works fine except that the members get a little confused
between Private Chat and Conference sometimes.  They tend to end up in
Private mode, just 'cause that's how you page somebody.  But then if someone
else wants to join in the fun, everybody has to quit and go to Conference
Mode, kinda confusing.  Since no one's seriously going to be talking about
anything REALLY private in such a forum, I decided to shuffle everybody over
to the Conference mode automatically.  You can check out my Internode menu to
see how I did it.  The "Make Connection" and "Chat Mode" are identical menu
functions.  The first time, they're instructed to enter the node number at
the prompt, the second time to just hit Return, thus entering Conference
mode.  They're notified when someone else enters the conference, anyways, so
they can clam up about that big bank heist they were planning.

  If one node freezes up, for whatever reason, and someone checks to see who
else in online, their node will freeze up, too.  I don't blame the program
for this one, it's trying to interrogate the other nodes and is expecting a
reasonable response.

* If there's another drawback to the program besides being limited to 100
sections, it would be that dumb hard-coded subcommand menu that the List
Files function, #20, calls up.  Why he just didn't give us the Search, List,
Alphabetical List, etc, functions by themselves, I'll never know.  Since he
modeled this, in part, on BBS-PC, which has separate functions, I'd have to
give him a big zero on this one.  If you see him, kick him in the butt and
say, "That's from Benchie for the stupid sub-command menu".  If you want to
be the one to cut off his little finger for that 100 sections thing, I'll
hold his hand down.

  About the best thing you can do with that subcommand menu is to make it as
pretty or plain (depending upon personal philosophy) as you can, since you're
going to be seeing it at every turn from here on out.  What's bad about it is
that the members will be in some section, like Audio Tools, see that N)ew and
hit it, forgetting they're at present only searching for N)ew audio tools,
not the whole board.  And the Search, excuse me, "Find" is even worse, as
they'll think there's no <whatever> on the board, 'cause they've unknowingly
just searched that one section.

* A small decision for you to make: Whether or not you want to "filter out"
non-Amiga members from the very beginning.  If you do, then make your
login.text a regular binary ANSI file with LaDraw.  Any IBM'er or Mac user
who isn't completely ANSI-ready probably won't even get to the logon prompt!
Cool, huh?  If you want to allow all IBM and Mac users, etc, in, then make
sure the login.text is plain ASCII, so they can at least log on, then turn
the ANSI off as they register.  For what it's worth, my login.text is VERY
binary. :)

* Okay, let me sum up this Link business.

  Let's say you're putting all the regular stuff in Link 1, your erotica or
other exclusive files in Link 2, and your really private stuff in Link 3.
We'll keep them separate for now, you can put files in two or all three
Links.  The word "Area" would have worked much better here.

  Our three key section numbers are 100, 101 and 102, for Links 1, 2 and 3.
Sorry the numbers don't line up, blame the Arabics.  You'll use them for
functions #20 and #24, List and Download.

  On most file menus, after the List function, you'll have a section number
in the Extras box, so that's all they'll be able to see.  On your main Files
Menu, you'll have a function 20, but no section number, that's when you use
100.  So when the members use the Find or New feature, they scan the whole
board for everything in the Link 1 area, the PD stuff.

  Now let's say you have your Exclusive Files menu.  Again, if they're just
listing a specific section, you just slap the section number in the menu.  If
you want them to be able to search all the exclusive files, Link 2, that's
when you'd use the 101 in the Extras box.  Make sense?  If you had a section
that you wanted to be seen from either a 100 or a 101 option, that's when
you'd checkmark both Links in the Sections Menu.

  When it comes to downloading, he did something kind of tricky.  Any files
that you have access to, that you see listed and can Mark for auto-download-
ing, can be downloaded from any menu, no matter what's in the Extras box.
Otherwise, when you try to enter the file name by hand, the 100/101 business
applies,.  All your regular menus will have a 100 in the Extras box for every
Download command, except in the Exclusive Files menu, which will have a 101.

* Have you seen my overlapping menus yet, like Options/Stats?  Lots of
potential here for neat menus.  Other examples are the Files Menu, the Online
CD-ROM Menu, Bulletins/Info and Animations.  The big trick here is the Join
command.  If you check out the Menus drawer, you'll see seven pieces for my
Animations Menu.  Four are from LaDraw, and three are the pyramid eye,
chopped into thirds with CygnusEd.  You'll see the scriptfile for Joining
them in the MenuMake drawer.  The others need Joining because of where I want
the cursor to end up.  I first make the menu, save it like yes-yes-full, then
clear the screen, place the cursor where I want it to end up, then save the
second menu in "overlap mode" (no-yes-no-up to), then Join the two pieces.

* You'll definitely want to spend some time with that VERY nice Text Config
Menu, personalizing things.  Tres cool, Antonio.  That almost makes up for
the awful 100 sections limitation.  Here, you can have your finger back.

* The "auto insert codes", the % things, can be read by everything.  You can
put them at the bottom of menus, like "At your service, %R:", which would
display the user's first name, and they work in any textfile or door.
Actually, they HAVE to work in any textfile or things won't stop at the
bottom with a %Z. I used every one I could in a "Personal Letter From
<you>", the enclosed "hi.txt".  Just something for the members to trip on.

  Remember, when you save a menu with auto-insert codes with LaDraw, you use
yes-NO-up to.  Keep that LaDraw mini-doc handy!

  Speaking of LaDraw, if a textfile is just one screen in length, try making
it a binary ANSI file with LaDraw.  Put a %Z at the bottom like usual and
save it full screen.  You still use function #13, "type a file", but it'll
display it TWICE as quickly as a regular textfile.  If your text editor
allows you to insert a screen clearing code (^L), then that's best, in that
it will also display pretty quickly but will still editable with a text
editor.  Note:  Most of these textfiles have a ^L at the beginning.  If you
edit and save them with Ed, you'll lose it, and you need a smarter text
editor.  Did I mention CygnusEd?  Great tool.  If you buy one piece of
software this year, that should be it.

* Ah, doors.  Feel like learning a little C?  Okay, from what I can glean, a
"door" means that Max is expecting some kind of input; window, requester,
whatever, on its side of the screen.  In other words, if you run the Clock
from Max's function 27, Run External Program, the Clock will pop up, all
right, but right where it's supposed to, on the Workbench screen.  A "door",
function 34, lets whatever it is be opened on Max's screen.  (but no, not the
Clock)  In still other words, it takes care of switching over all the IO
ports and stuff.  That "stuff" is one of those technical C terms I was
talking about.  You can tell I know a lot about this.

  If you DO know some C, there are some door-maker programs out there for
Max's on the Internet.  Find an Aminet site, go to comm/bbs and look for
stuff for Max's.  I haven't been able to get any non-Max doors to work.  A
Chess game did, but the screen res & colors was all wacko.

  Oh, two important notes:  most of the doors I've tried freeze up at local,
have to be accessed from remote.  Also, many of them look for "MAXsBBS.-
config", so if you're running multiple lines, or made your own custom .config
file, you'll want to make a copy of it for the door program.

  Some doors, like MultiBltn, you'll want to use immediately.  MultiBltn's
only hitch is that it only displays them one per visit, so if you have
something urgent to say, and some member hasn't called for a while, and
you're on #16 and he's on #13, he won't see it.  I use the built-in bulletin
text for immediate, important notifications, MultiBltn for normal stuff.

  BigClock is just a hack, but cute.  Run it from a menu saved with no screen
clearing codes.  Some other doors need that roll-up type of menu, too.

  I'm using the Vote door to make my members take a fake little "R-Rated
Test" before allowing them access to the erotica.  Seems to work fine.  One
cool thing the program does is display the vote tallies in percentages rather
than numbers.

  I'm using the ProgramRequest door as part of my "online rendering with
ADPro", a side function I have on my board so the members can convert the GIF
pics from the CD Of The Month to HAM, JPEG or AGA.  I'll enclose the script-
file in case you want to try something similar.  I should point out that I
wouldn't have been able to do it without my best buddy, FakeKey.

  Update Note:  I'm also using it now for the Fred Fish CD.  There were so
many sub-directories and sub-sub-sub-directories that I gave up having any
hope the members would be able to hack the pathnames.  I use the ProgReq door
to let the member enter the filename, then I have a smart scriptfile
debinaryize out the ANSI garbage, put a "Copy" command in front of the
filename, a destination directory after it, then the file is saved and
executed, hopefully finding the file and copying it to the the Download
directory.  Scripts are included if you feel brave.

  Max's doesn't use ARexx doors, but a few of them can be gotten around.  I
have an ARexx door that tells the current phase of the Moon, so I output >
the rexxfile to a text file, then have the members read that.  The "Update
Moon Phase" is "Execute BBS:Doors/Moon/moon.scp".  The "moon.scp" is "rx
>BBS:Doors/Moon/phase.txt moon.rexx".  It rx's the moon.rexx file to a text
file called "phase.txt", which is then read from the menu by another command.
That works okay for something that just outputs a textfile; for an ARexx
program that opens a window or something, it wouldn't.

* You'll note that when you log off the BBS locally, the logout.text flips
off when it's through, since it doesn't have a %Z at the bottom.  This is
correct, otherwise the members would have to hit the Return one more time to
log off.  That "ciao fer now" is box #28 of the Text Editor, and it's a fun
thing to routinely change.

* Oh, by the way, my initials as The BenchMaster are TBM, but I had nothing
to do with that "TBM.font" business, it's purely cosmic.  He doesn't say what
it stands for in the manual, just says the program wants them.  They sucked,
looked like stock Topaz, so I included the ones I use.  These are true IBM
ANSI fonts that I "Amigalized" for that crisp, clean look.  Nice interlace
system font, too.

* When you run "your" node, make the scriptfile say "MAXsBBS -s <config>",
that'll open it up in sleep mode, so it won't disturb the modem.

* If you happen to be going 28.8, remember that the modems will check for
line noise, etc, and will often connect at a lower rate, like 26.4, 24.0,
etc.  This is good, of course, that the modems are so smart.  As of this
writing, there aren't any strict standards for 28.8 yet, so if the 28.8
members have connect and/or transfer problems, have them call at 19.2 and
see what happens.

* I let Random pick a different color for the file size/date line every day.
I just couldn't decide what color I liked best, so I finally said `screw it'
and let Random take over the task.  Once a day, in the wee hours, a script-
file is Executed which runs Random, which copies one of six files over to a
certain filename.  The scriptfile then makes fresh, patched config files for
the other nodes, then patches just the two spots that change the color of the
file size & date lines.

* If someone's online, and you want to slip them a file that isn't on the
board, there are three ways to do it.  If you want to log the file onto the
board like normal, just go to your node, pop open the Files Editor and log
the sucker on.  When you save it, it'll immediately be accessible.  If you
want to slip them something on the side, you can either have them raw
download it, or you can leave a message for them and File Attach the sucker.
The fact that you can attach it from Local is pretty cool.  I have a couple
of Raw Download areas on my board, so I just skip over to one of them and
down it comes.  Note:  As you're about ready to guess, this also means that
the users could Raw Download anything from any of your drives, as long as
they know the correct paths.  My answer:  So what?  What are they going to
do, download your valuable startup-sequence?  They won't know the paths to
any private files you have, and if they (finally, after hours and hours of
trying) figure out that all your Audio files are in a partition called
"AUDIO:", again, so what?  What are they going to do, start downloading lots
of board files?  Good! :)

* Speaking of loading a file while someone's online, in case you missed it,
he says in the manual that this is perfectly okay, just don't DELETE a file
while someone is online.  Sounds good to me.

* This may sound trivial, but if you want your files to look "nice" when
listing them, you'll probably want them either all capitalized, or all not.
If you decide on capitalized, and your LHA program saves the tag as ".lha",
you can file-zap the program to have it spit out the ".LHA" in all caps.

* The Check Files function works just dandy, and it works a lot faster and
smoother if you really jack up the buffers to the devices your files are in.
Interrupt the startup-sequence so you've got max mem, then run AddBuffers all
over the place until you've just got enough mem left to fire up the program
and run the Check Files routine.  More buffers for the devices with the most
files in them, less for the smaller.  Here's how you test how much you need:

> interrupt st-seq
> AddBuffers 500 <device>
> Dir >nil: <device>
> Dir >nil: <device>

If the drive light blinks during the second Dir, you don't have enough
buffers yet.  Do an "AddBuffers 100 <device>", then the two Dirs again, and
keep adding buffers until the drive light doesn't blink.  Add it all up,
reboot, interrupt the st-seq, then "AddBuffers <whole number> <device>" and
then Dir it twice to make sure it works.  Do that for each device you have
files on, and if you've got extra mem, add more buffers to allow for future
growth.

When you want to check the files, reboot, interrupt the st-seq, then Execute
your "Checkfiles.scp" scriptfile, which will say something like:

SetPatch >NIL:
BindDrivers

CPU >nil: FASTROM ; plus any other mem enhancers you have
FasterBlit >nil:
CopyMemQuicker >nil:

AddBuffers anims: 1000
AddBuffers audio: 1100
AddBuffers elite: 1000
AddBuffers games: 1100
AddBuffers graph: 1100
AddBuffers pics: 3600  ;2,400 pics <blush>
AddBuffers misc: 1800
AddBuffers bbs: 200
AddBuffers utils: 1600

Dir >nil: anims: all ;this `preloads' everything into memory
Dir >nil: audio: all
Dir >nil: elite: all
Dir >nil: games: all
Dir >nil: graph: all
Dir >nil: misc: all
Dir >nil: pics: all
Dir >nil: utils: all

CD BBS:
Run >nil: MAXsBBS -s


Note: The BBS device only gets a nominal 200 buffers, even though the
file.data file is on it.  The CheckFiles function just reads a tiny bit of it
at a time, so pre-loading it wouldn't do much good.  When you see your drive
light blinking occasionally, that's what it's reading.

* The "Import Text" pull-down menu function is your local ASCII upload for
the message base.  Right-hand margins set to 75, 99 lines limit, no need to
worry about blank lines.  Accepts ANSI characters, like box outlines, but not
colors.  That's still something, though.  When I got the new software going,
I tried ASCII-uploading ads to other local boards, and not ONE of their
editors accepted the box outlines.  Humph.

* I wouldn't dream of being some lackey server to some fidonet hub, so I
don't know a thing about the fidonet functions, in case you were wondering.
People who ain't got nothin' better to do than sit around all day reading
mail ain't my brand o' people.

* The Printer/Output pull-down is how you make a capture buffer of the screen
events.  Unfortunately, it flips off when the user logs off, so you can't
leave it on all the time in anticipation of catching someone in the act of
doing something bad.

  Unless, of course, you have FakeKey at the ready. ;)

  I haven't tried it, but I imagine you could run a door when someone logs on
(Doors:MainDoor.text) that would run a FakeKey/MovePointer scriptfile that
would open the capture buffer.  In theory, it should be pretty easy to write
an actual door program to open the buffer.  In theory.

* If you want to edit a user's stats while he's online, use the pull-down
Online Edit from his node.  When you close the box, his new stats will be
saved and effective immediately.

* I don't use an up/download ratio.  It might "work", but it still sounds
like one of the dumbest ideas I've ever heard of.  It encourages junk to be
sent up, and you should be more into quality than quantity.  I get less
uploads than other boards, but when I see something in my Uploads Bin, I know
its heartfelt.

* Guests can't leave PD or private messages, so assholes can't leave nasty
messages to everyone at 3 in the morning, but they do have write access so
that they can leave private mail to you.  They also don't have download
access (on the menus), but they do have general download access so they can
download some specific files (NComm, AmiFonts, etc) from a special Guest
Menu.

* I don't believe in putting a DOS window *anywhere* on the board, not even
some "Private SysOp's Menu", so I really don't worry about BBS hackers too
much.  As long as they can't get into a CLI and type "Delete #?:#? all",
that's all I care about. :)  I haven't found, or heard of, any chinks in this
stuff's armor.


  Well, between the manual and this little doc, things should be (relatively)
smooth sailing!  Any questions, give a holler.


                                        Benchie

Amiga-only BBS:
[phone]

[e-mail]